Projet Zuul: Exercice 7.49.1 (OPTIONNEL)

Forum des exercices du projet Zuul

Exercice 7.49.1 (OPTIONNEL)

Vous n'êtes pas abonné à cette discussion. Cliquez pour vous abonner.

Expliquer l'utilisation (s'il y a lieu) de l'héritage entre les classes Item, Player, Character, et pourquoi pas SpecialCharacter (voir les exercices 9.10 et 9.11 du livre).

Permalien | Modifier | Supprimer | Répondre

Un étudiant a écrit :

Bonjour, vu la proximité entre un Player et un Character, je pense que Character peut hériter de Player. Est-ce correct ?

Cordialement.

Ne trouvez-vous pas qu'il y a pas mal de choses dans Player qui ne serviront pas à Character ?

Ne vaudrait-il pas mieux que Player hérite de Character ?

Sauf s'il y a des choses dans Character qui ne servent pas à Player. Dans ce cas, comment peut-on utiliser malgré tout l'héritage ?

Ah, j'avais l'impression que Character avait des fonctionnalités plus spécifiques qu'un player.

Du coup pour utiliser malgré tout l'héritage, on peut déclarer des méthodes de Character inutiles pour Player private pour en empêcher l'héritage.

Attention : l'héritage ne doit être utilisé que si cela a un sens, c'est-à-dire qu'on peut dire que A est une sorte de B.

Il ne s'agit pas d'affirmer qu'un Item est une sorte de Room juste parce qu'elles ont un attribut aDescription en commun par exemple ...

Puisque vous devez constater que Player possède des caractéristiques qui n'ont pas de sens pour Character et vice-versa, mais que ces deux classes ont des caractéristiques communes, comment peut-on quand-même utiliser l'héritage dans cette situation ?

Je ne vois pas vraiment comment faire. A part déclarer des attributs static pour empêcher leur réécriture dans la sous-classe. Ou encore faire une classe abstraite ou même une interface qui reprend les choses qui sont pareilles dans player et character et du coup avoir player et character qui heritent ou implementent la même base de méthodes et d'attributs.

"Je ne vois pas vraiment comment faire."

??? vous prouvez le contraire ci-dessous ...

"... faire une classe abstraite ... qui reprend les choses qui sont pareilles dans player et character et du coup avoir player et character qui heritent ... la même base de méthodes et d'attributs."

pourquoi cette idée ne vous convient-elle pas ?